![[レポート]データベース移行を検討する際のベストプラクティス #reinvent #JAP201](https://devio2023-media.developers.io/wp-content/uploads/2021/11/eyecatch_reinvent2021_sessionreport.png)
[レポート]データベース移行を検討する際のベストプラクティス #reinvent #JAP201
みなさんこんにちは、杉金です。
AWS re:Invent 2021で行われた「データベース移行を検討する際のベストプラクティス」セッションのレポートです。
セッション動画
本セッションの動画はこちらです。
セッション情報
SPEAKERS
新久保 浩二 氏
アマゾンウェブサービスジャパン合同会社
技術統括本部
レディネスソリューション本部データベースソリューション部シニアソリューションアーキテクト
DESCRIPTION
オンプレミスのデータベースをAWSに移行することで、商用ライセンス、運用負荷などのコスト削減を検討されるお客様が増加しています。このような状況の中、データベースの移行を検討する際の一般的なステップやAWSが提供している移行に役立つツール、サービスについて説明します。また、いくつかデータベース移行の実例を見ながら移行を検討する際のベストプラクティスを紹介します。(なお、本セッションでは各データベースエンジンに特有の非互換性の書き換えなどの細かいTipsなどは含まれません)
SESSION ID
JAP201
SESSION LEVEL
200 - Intermediate
アジェンダ
- AWSデータベース移行の勢い
- AWSのフルマネージドデータベースサービス
- データベース移行を検討する際のステップ
- データベース移行を支援するツールやサービス、各種プログラム
- まとめ
AWSデータベース移行の勢い
- 450,000を超えるデータベースがAWSに移行されている
- 2016年にリリースされたDMSサービスを利用して移行したDBの数
- DMSを利用しないDB移行を含めると更に多い
AWSのフルマネージドデータベースサービス
- セルフマネージドとフルマネージドの比較
- セルフマネージド
- データセンター契約
- HW調達、設置
- DBソフトウェアのインストール、設定
- セキュリティの設計、実装
- フルマネージド
- 素早く利用するために多くのタスクを自動化している
- 設定変更をマネジメントコンソールやCLI(API)から簡単に実行できる
- DBを使うこと、管理することに多くのリソースをかけるのではなく、 ビジネス上の課題を解決するために、アプリケーション開発/最適化にリソースを集中できる
- セルフマネージド
- フルマネージドデータベースのメリット
- 俊敏性の向上
- 必要に応じて素早くインスタンスを作成、削除ができるため開発サイクルの短縮化が期待できる
- コスト削減
- 必要な時に必要なだけDBをサービスとして利用して不要なコストが発生しない
- 性能と拡張
- 常にピーク性能のリソースを用意していく必要はない。ビジネスのニーズに合わてスケールアップ/ダウンが簡単にできる
- 迅速なイノベーション
- HWの調達や構築などの複雑ではあるもののビジネスとして差別化できない作業をAWSにオフロードができる。アプリケーション最適化や新たなサービス開発などのビジネスに直結するタスクに集中できる。
- 俊敏性の向上
- フルマネージドデータベースサービスへの移行
- 用途の応じて様々なDBエンジンを用意しているのも大きな特徴のひとつ
- Relational databases（幅広い用途）
- Oracle、SQLServer、PostgreSQL、MySQL、MariaDB、Aurora
- Nonrelational databases（ユースケースに最適化されたもの）
- mongoDB、Cassandra、redis、Memcached
データベース移行を検討する際のステップ
- 5つのステップからなる
- 1.Assesment（サイジング実施、スキーマ、SQL移行の難易度を調査）
- 2.Schema conversion（スキーマの移行）
- 3.Code conversion（SQL（DB、アプリ）、プロシージャー）
- 4.Data migration（データの移行）
- 5.Validation（データ移行の正常性をテスト）
- 1.Assesment
- 移行先のデータベースのサイジング
- 必要なパフォーマンスがAWSで出るのかの確認
- アプリケーションやオブジェクトへの影響と変更の必要性、変更が必要な場合にどの程度の難易度になるかの確認
- 決められた予算、期間でDB移行できるかの確認
- 2.Schema conversion
- DBの器（スキーマ）を移行
- 3.Code conversion
- DB内のオブジェクトを移行
- アプリケーション内のSQLを変更することもスコープに含まれる
- 4.Data migration
- 5.Validation
- データ移行の正常性をテスト
- 最初のAssesmentが重要
- DBエンジンを変更するかどうか
- DBエンジンを変更する場合
- SQL、関数、プロシージャなどの互換性がないものがあるため移行前のアセスメントが重要
- スキーマに加えてアプリケーションの変更も必要になる場合が多く移行工数は相対的に多い
- DBエンジンを変更しない場合
- スキーマ、SQL、プロシージャで互換性が担保されるため比較的に移行工数は少ない
- 同一エンジンのAmazon RDSに移行する場合でも、実行できないSQLが存在するため移行前のアセスメントは重要
データベース移行を支援するツールやサービス、各種プログラム
- 移行フェーズ：Assesment、Schema conversion、Code conversionをカバーするツールとしてSchema Conversion Tool(SCT)が利用できる
- 移行フェーズ：Data migration、ValidationでDatabase Migration Service(DMS)が利用できる
- DMSでは同一DBエンジン同士や、異なるDBエンジン同士でもデータ移行ができる
- Database Freedom Workshop(無償)：Assesmentフェーズで利用
- Database Migration Accelerator(有償)：Schema conversion、Code conversionフェーズで利用、コードの書き換えを支援
- データベース移行全般をAWS Professional Serviceやパートナーのサービスで支援可能
Schema Conversion Toolによるデータベース移行アセスメントレポート
- SCTを使用したレポート生成の流れ
- 移行元のデータベースに接続
- 移行先のデータベースを指定
- SCTによる自動変換率をレポート
- 手動変換にかかる移行工数(時間)を確認
移行元データベースのワークロード分析によるサイジング
- 現時点でAWSから自動でサイジングするサービスやツールは提供されていない
- 移行元の既存データベースの実ワークロードからパフォーマンス観点でのサイジングを行うことも重要
- 例）OralceであればAWR/statspackレポートを使う。以下の観点でサイジングを実施
- 全体ワークロードの概要
- CPUリソース
- I/Oリソース
- メモリーリソース
- 例）OralceであればAWR/statspackレポートを使う。以下の観点でサイジングを実施
移行元の実ワークロードに基づかない不適切なサイジングの例
- 例）オンプレミスのデータベース（CPU：48コア(96スレッド)、メモリ：768GiB、ストレージ：30TiB）
- AWS上で必要なインスタンスサイズとしてオンプレミスと同じキャパシティのものを選んだ
- 実際のワークロードを分析していないため、クラウドの柔軟性を活用できていない可能性が高い
- 実際のワークロードを計測するとCPUがほとんど使われなかったり、ストレージも空き容量が多くあり過剰なサイジングになってしまう
Database Freedom Workshopについて
- ワークロードレポートの分析、サイジング
- SCTアセスメントレポートの分析
- 移行先データベースの選定、移行先データベースに関するDive Deepセッションの提供
- データ移行方式について実現性の検討
- 移行リスク、PoCすべき点の抽出の支援
Schema Conversion Toolによるスキーマ変換
- ツールの左側：移行元オブジェクト
- ツールの右側：移行先オブジェクト
- ツール中央：自動変換時のメッセージ
- 変換されたコードやDDLをローカルPCに保存でき、直接移行先のDBに対してオブジェクトを作成することもできる
Database Migration Accelerator(DMA)の特徴
- SCTで全てのオブジェクト、コードが自動で変換されるわけでない。手動変換が必要なものもある
- JavaやPHPなどのDBより外のコード変換はSCTだけでは自動変換が上手くいかないことも多くある
- これらの課題を課題を解決させるために有償でDatabase Migration Acceleratorプログラムを提供している
- コード変換のエキスパートがコード変換を実施する
- 複雑レベルに応じた固定の価格を提示、変換にかかる工数が予定より長くかかっても価格は変わらない
- 基本的に商用DBからオープンソースDBへの移行を目的としている
- 本プログラムで変換作業を短縮できる
Database Migration Acceleratorのイメージ
- 最初のステップとしてQualificationと呼ばれるものがある
- あらゆるアプリケーションをDMAで取り扱えるかというとそうではない
- SCTのアセスメントレポートであったり、実際のアプリケーションコードを確認してDMAでコード変換可能か確認する
- DMAで対応可能とAWS側が判断した場合にDMAのチームがスキーマ変換、テストデータの移行、アプリケーションコードの変換を実施する
- 最終的に移行後のスキーマ定義、DMS設定値、変換後のアプリケーションがお客様に納品される
データベース移行のデータ移行フェーズ
Database Migration Serviceによるデータ移行
- 比較的要件が厳しい場合にDMSによるデータ移行が選ばれる
- 移行元DBからニアリアルタイムでデータ同期ができる
データベース移行を支援するパートナー
- AWS Oracleコンピテンシー取得パートナー
- サービスデリバリープログラム(SDP)取得パートナー
まとめ
- DB移行を検討する場合、移行の基本的なステップとしてアセスメント→変換→データ移行を考え、まずアセスメントを実施しましょう
- アセスメントでは、実ワークロードの分析や移行難易度の分析を行い、移行先の必要リソースや移行工数を見積もりましょう
- アセスメントでは、SCTや移行元データベースが持っているワークロードレポートを利用しましょう
- AWSが提供しているDatabase Freedom Workshopによるアセスメントの支援、Database Migration Acceleratorやパートナーから提供されている各種移行プログラムの活用も検討してください
感想
DMSを使ったデータベース移行は何度か経験があるのですが、アセスメントの重要性は過去の記憶を思い返して、反省とともに身に沁みて伝わりました。アセスメントは移行方法の確認だけでなくサイジング、パフォーマンス、影響、予算など考慮すべきポイントは広範囲に渡っており、どれか一つでも欠けていると移行スケジュールがタイトになったり、移行後にパフォーマンスが十分に出ないなど、やっかいな問題に出くわす可能性が高まります。提供されているツールやプログラムを十分に活用することで問題回避に役立つことは間違いありません。re:inventではDMSに関するアップデートもありましたので、このベストプラクティスとともに今後活用できればと思います！
![[ワークショップ] マルチテナント要件を達成するためのデータストアの分割方法を学ぶ「Build a multi-tenant SaaS solution using AWS purpose-built databases」に参加しました（DAT402） #AWSreInvent](https://devio2023-media.developers.io/wp-content/uploads/2023/11/eyecatch_reinvent-2023-session-report.png)
